iT邦幫忙

2021 iThome 鐵人賽

DAY 3
0

前言

上一篇談到戰略資訊系統的分層設計,要如何進行呢? 中大型企業一般會請管理顧問公司或IBM/HP...等資訊服務公司,協助規劃,辦理一些共識營的活動,擘劃企業願景、凝聚共識,進而展開至各事業群,訂定未來方向,這種由上而下(Top Down)的方式,可以確保企業目標可以藉由各部門的分工與合作,順利達成。領域驅動設計分為戰略與戰術設計,其中戰略設計也是類似的方式,事件風暴(Event Storming)就是與領域專家、使用者與開發團隊凝聚共識的方法。

系統分析方法論的演進

領域驅動設計並不是橫空出世,而是經由過去幾十年的逐步演化而成的,它是一種系統分析與設計的方法論,現在系統開發人員幾乎不太注重系統分析技能了,學校也不注重了,大部分人都是畫幾張『使用案例圖』(Use Case Diagram)、『類別圖』(Class Diagram)交差了事,對於複雜的流程,了不起再補張『順序圖』(Sequence Diagram),這樣的作法見樹不見林,只注重系統設計,不管系統分析,如此進行中大型系統的開發,幾乎註定要失敗。
https://ithelp.ithome.com.tw/upload/images/20210918/20001976tZT707fqND.png
圖一. 使用案例圖(Use Case Diagram),圖形來源:維基百科

https://ithelp.ithome.com.tw/upload/images/20210918/200019762OMMTBoLXI.png
圖二. 類別圖(Class Diagram),圖形來源:ResearchGate

https://ithelp.ithome.com.tw/upload/images/20210918/20001976cZ2XCo5zW9.png
圖三. 順序圖(Sequence Diagram),圖形來源:Zim - A Desktop Wiki

隨著中台架構/領域驅動設計的聲量變大,筆者很高興熱潮又擺盪回來了,大家又開始討論系統分析方法論了,領域驅動設計可以搭配各種開發框架及設計模式,使開發者願意更進一步的將分析與設計做好,形成『分析/設計/開發』一貫的流程,它不像UML,只提供圖形工具,參見下圖,領域驅動設計則有一套完整的方法論(Methodology),也就是遵循步驟,就可以順利的將系統開發出來。當然不保證功能一定會符合使用者的期望,因為那是屬於分析技巧與甲乙雙方認知的問題。
https://ithelp.ithome.com.tw/upload/images/20210918/20001976nl0l92ML97.png
圖四. UML圖形工具,圖形來源:維基百科

筆者一路看著系統分析方法論的進展,覺得非常有意思,從『結構化分析與設計』(俗稱DFD)、UML/RUP到領域驅動設計(DDD),舊的思維不斷的補強,成為更新、更完整的工具,例如:

  1. DFD以 System Context Diagram 描述系統與外部系統的介接,藉以框住系統的範圍,DDD 轉化成 Bounded Context。
  2. DFD Level 0的事件列表(Event List),DDD將之強化為『事件溯源』(Event Sourcing)與『命令和查詢職責分離』(CQRS)。
  3. 物件導向程式設計(OOP)興起,UML的類別圖(Class Diagram)變成顯學,DDD則進一步強化為領域模型,並引入聚合(Aggregate)/聚合根(Aggregate Root)/實體/值對象等概念。
  4. 系統設計階段導入各種設計模式(Design Pattern),包括Repository/Factory/Facade...等,配合各種現成的框架,如Java Spring、MS MVC、ORM等,期望一氣呵成的完成相關系統的開發。

https://ithelp.ithome.com.tw/upload/images/20210918/20001976bTsQUixbrv.png
圖五. System Context Diagram 與 Bounded Context 比較,圖形來源:微軟DDD文件指引維基百科

領域驅動設計

講了那麼多,領域驅動設計的分析流程是甚麼呢? CQRS Journey畫了一張很有趣的圖,分為8個步驟,也附了一本書說明詳細作法。
https://ithelp.ithome.com.tw/upload/images/20210918/20001976X1zKAiUvXa.png

不過,筆者比較喜歡另一本書『中台架構與實現:基於DDD和微服務』的思維,針對它建議的流程,稍作修改如下圖:
https://ithelp.ithome.com.tw/upload/images/20210919/200019767jJdC3ulgF.png
圖六. 領域驅動設計流程

在後續的文章,我們會針對每一步驟做詳細說明。

結語

看到那麼多的縮寫字、專門術語與圖形,讀者應該很頭痛,畢竟研究任一種方法論,都要花很多時間閱讀、理解進而實作,但是回報也是呈正比的,筆者就曾經靠『結構化分析與設計』方法論,獲得兩、三個工作機會,也靠這套方法論,完成數十個應用系統的開發,現在面對『領域驅動設計』的熱潮,也是值得再投入時間,將自己的檔次再提昇一級。

下一篇,我們會先依照系統分析方法論的演進過程,先介紹早期的『結構化分析與設計』(DFD),說明其優缺點,再逐步比較領域驅動設計對應的作法。


上一篇
【Day 02】戰略資訊系統(Strategic information system)
下一篇
【Day 04】阿公級的系統分析方法 -- DFD
系列文
淺談中台架構、DDD與Python實踐10
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

1
JC
iT邦新手 2 級 ‧ 2021-10-18 02:01:20

大哥加油~~~ 很期待您的文章 覺得內容組織的很好

感恩,動力+1。

我要留言

立即登入留言